I think we don't need to worry about net6.0 as it's out of support and we'll probably remove it as a build target after the next release. The inability to use with net472 or netstandard2.0 is a greater loss and it might be worth a quick test to see how hard it would be to add support for those.

Thanks for the review! I'll take a look at your comments over the next few days and follow up.

Nice tests!

It would be nice to avoid adding all these targets. Is there something bitness-specific in these changes?

Is this really true though? We use the type to infer the schema, not the data. It would be annoying for someone to have to special case an empty list if they want to serialize it.

Consider moving schema above the foreach and adding the fields directly into the schema builder instead of a temporary list.

What would it take to make this work for .NET 4.7.2? Is that even plausible?

the library now targets netstandard2.0;net462;net8.0 (matching Apache.Arrow), with tests passing on both net8.0 (197) and net472 (182 — the gap is only DateOnly/TimeOnly/Half, which don't exist there). To make that possible, IArrowSerializer changed from static abstract members (which require the .NET 8+ runtime) to an instance interface resolved through a generated, module-initializer-populated registry — the MessagePack IMessagePackFormatter pattern — so the public extension API is identical on every TFM, still reflection-free and AOT-safe.

It might be worth pointing out in the documentation that a CLR decimal is not a perfect match for an Arrow decimal.

Consider a more descriptive name. What about ArrowTypeKind?

All open issues should be addressed.

Variant integration — separate PR or fold in here?

Since Variant landed in Apache.Arrow, I've prototyped a full serializer support for it on a local branch stacked on this one (~9 commits, 231 tests on net8.0 / 216 on net462. Before pushing anything: would you prefer this as a follow-up PR once this one merges, or folded into this PR? My instinct is follow-up — this PR is large enough — but happy either way.

A quick tour, in three layers:

1. VariantValue properties map to the Variant extension type — a column that holds any shape per row:

using Apache.Arrow.Scalars.Variant;

[ArrowSerializable]
public partial record Event
{
    public string Name { get; init; } = "";
    public VariantValue Payload { get; init; }
}

var evt = new Event
{
    Name = "click",
    Payload = VariantValue.FromObject(new Dictionary<string, VariantValue>
    {
        ["x"]    = VariantValue.FromInt32(10),
        ["tags"] = VariantValue.FromArray(VariantValue.FromString("a"), VariantValue.FromString("b")),
    }),
};

var restored = Event.FromRecordBatch(Event.ToRecordBatch(evt));
int x = restored.Payload.AsObject()["x"].AsInt32();   // IPC round-trips too

2. [ArrowType("variant")] stores any POCO/collection property as a self-describing Variant column instead of Struct/List — fully source-generated, recursive, no reflection:

[ArrowSerializable]
public partial record Order
{
    public Address Shipping { get; init; } = new();      // Struct column (default)

    [ArrowType("variant")]
    public Address? Billing { get; init; }                // Variant column

    [ArrowType("variant")]
    public Dictionary<string, double> Prices { get; init; } = new();
}

On read, missing fields default and unknown fields are ignored — old readers survive new writers and vice versa.

3. An alternative wire format for [ArrowPolymorphic] — instead of the flat discriminator + union-of-all-fields schema, one Variant column with self-describing rows:

[ArrowPolymorphic(Format = ArrowPolymorphicFormat.Variant)]
[ArrowDerivedType(typeof(Order), "order")]
[ArrowDerivedType(typeof(Ping), "ping")]
public abstract partial record Message;

// wire:
//   {"$type":"order","Id":"A1","Shipping":{"City":"Berlin"},"Tags":["a","b"]}
//   {"$type":"ping","Seq":7}

The schema never widens as derived types are added, and the flat union's property-type restrictions disappear (nested records, collections, and dictionaries all work). Flat union stays the default — it's the right choice for columnar analytics; the README has a trade-off table. There are also opt-in read policies (MissingFieldHandling / TypeMismatchHandling) for consuming foreign-written batches.

One piece you may want in this PR regardless: while testing IPC round-trips I found that extension columns don't rehydrate after ArrowStreamReader — ExtensionTypeRegistry.Default starts empty, so the generated (GuidArray) cast for the existing uuid mapping fails on any deserialized stream. The variant branch fixes this by registering the uuid (and variant) definitions from a module initializer (never overwriting existing registrations), plus a Guid IPC regression test. Happy to cherry-pick just that fix into this PR now if you'd like.